[Previous] [Next] [Index] [Thread]

Re: Netscape Changes RSA tree

I concur with many of Chris Wilson's comments on the certification
structure.  It is becoming clear by now, if it wasn't already, that when
dealing with interactions _between_ organizations, there is no such thing
as a "universally trusted party".  To trust complete strangers with
the integrity of resources that are critical to my company, but which the
strangers neither know nor care about, I would have to be, as they now say,
just a few bits short of a full key.

There are some other flawed assumptions, not in the RSA algorithm
itself, but in how the EDI standards committees, and RSA/EIT/Netscape et.
al., have modelled the the "digital signature" and the
certification/authentication structure:

* The assumption that a digital signature corresponds to the function
of a normal signature.  An autograph has functionality that a digital
signature does not (biometric), and a digital signature has functionality
an autograph does not (tamper detection).  Digital signatures
might more accurately be called "digital seals", but that doesn't
exactly capture their functionality either.  They are a new kind
of animal, with tremendious potential, but it's going to take a
real world experience to learn how to use them properly.  The
first metaphor that came to mind ("signature"), and the
first implementations or the first standards committtee decisions
on the matter, are hardly the last word; in fact they are
almost surely quite wrong.

* A narrow, fixed view of what a "signature" should mean, namely
that it relates to the thing signed.  But if we realize that
we are dealing with somethin g different from a signature we
realize that there are more possibilities.  For example, in digital 
cash we use key-based semantics: the meaning of a "signature" is a 
denominaton of a coin, and it is based on the key used, not the 
contents of what was "signed" (which in our case is a random number 
used as a special kind of identifier).

* A narrow, fixed view of what a certificate should
mean, namely that it should certify that a key belongs to
a particular well-identified person.  It has been pointed out that
_offices_ such as president, treasurer, duty officer, etc. can have their
own keys.  It is also common for programs, such as servers, to have their
own keys.  _Resources_ can have their own keys, just like we do with
physical keys for houses, cars, etc. which we often loan to trusted friends.
There are a wide variety of possibilities inherent in the use
of keys, and thus in what keys used to sign other keys could
mean.  Since we really don't know all the possibilities, the
best implementation is to leave an open text field for
specifying any claimed property of the certified key into
the certificate, instead of assuming that a signature on a key
always must refer to one quite restrictive meaning.

* The assumption that strong authentication is necessary for
business transactions.  In the real world, weak authentication,
auditing, reputation, and good communications are usually sufficient.
The latter three are necessary even given strong authentication,
and others (such as confidentiality and privity) are also often
desirable.  We have, IMHO placed too much emphasis on a futile attempt
to do strong authentication, and too little on the other
important aspects of doing business.

------------------------------------------------------------
These view do not necessarily reflect the views of Digicash bv.

Nick Szabo
szabo@netcom.com
nick@digicash.com
http://www.digicash.com/~nick/
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.1

mQCNAy9wYzAAAAEEAMaP1xpCnkIe/2UC2M7EJPMjSUF5BzJb3OCEROr00AzXplPY
UrpKRaNu42Oh6G3q8RcTWCZ1qZXbZelDTMTFyCL23gs+hHB8suKuAlleqELSGr4m
9mkoMBGzKh5xuUJQYG+rtdJCm3tSijCHxZZtHsVmZUsaK4RrNiCygoHHhZGFAAUR
tB1OaWNrIFN6YWJvIDxzemFib0BuZXRjb20uY29tPg==
=ZEvk
-----END PGP PUBLIC KEY BLOCK-----
Follow-Ups: References: